home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1995 April / Internet Tools.iso / infoserv / www / cern / doc / www-talk.archive.Z / www-talk.archive / text0130.txt < prev    next >
Encoding:
Text File  |  1992-11-30  |  1.8 KB  |  42 lines
  1.  
  2.  
  3. >My question is on a fairly minor point of your document, you mention that 
  4. >a MIME document typically consists of a content and then the pointers, 
  5. >with the hypertext links being references to the pointers.
  6.  
  7. Well, this is not typical, but it's the model I'm proposing for
  8. hypertext. Typically MIME message bodies are either single part
  9. text/image/audio, or multipart. The standard multipart types
  10. are mixed, meaning "show these one after the other," parallel,
  11. meaning "show these at the same time," or alternative, meaning
  12. "these all represnt the same info. Take your pick."
  13.  
  14. The "content and then list of pointers [or attachments]" model
  15. is my own proposed format for hypertext.
  16.  
  17. >  In Wais, it 
  18. >is quite possible to return part of a document (by byte position), and 
  19. >if the pointers are part of the document itself then they may not be 
  20. >returned at the time the user chooses to try and follow a link? 
  21. >
  22. I would suggest that the WAIS server interpret the byte positions
  23. as offsets into the content part of the hypertext. So the structure
  24. remains in tact. Byte offsets into a MIME multipart message
  25. don't mean much. Transport systems may mess with the headers and
  26. trailing whitespace on body lines. Line offsets may be meaningful
  27. inside text body parts, as long as none of the lines have to be
  28. split due to line length constraints.
  29.  
  30. Keep in mind that this multipart structure is only necessary for
  31. hypertext (i.e. contains links) and hypermedia (i.e. contains
  32. multimedia attachments) documents.
  33.  
  34. Traditional documents can be simple single part bodies. For example,
  35. A plain text file starting with a new-line will be interpreted as
  36. a body part with no headers, which defaults to the type
  37. "text/plain; charset=US-ASCII" ,i.e. plain old text.
  38.  
  39. >My concerns are around doing these things for users on low-speed (2400 baud)
  40. >modems....
  41.  
  42.